今天聊一个老生常谈的问题：为什么使用 Spring Framework？

以下仅仅是根据个人的经验来谈论这个问题，仅供参考。

首先，我们需要达成一个共识：类相互之间必须存在依赖关系，才能支持业务系统，才能让软件系统更健壮，更灵活，更有可扩展性。

其实，将所有的业务逻辑在一个类内全部实现并不是不可以，但是这样其实违背人类偷懒的本性（扯大旗），我们总是想可以重复使用东西，减少使用成本。而提取可重复使用的过程就是软件开发中的抽象，而抽象和复用也是软件开发中的基础思想。当然也是因为抽象和复用，类与类之间就必然出现了依赖关系。

所以，因为一个健壮的系统，类与类之间必然存在依赖关系，类和方法必然存在抽象和复用。

其次，在达成上述共识之后，我们需要向办法简化类与类之间的依赖关系管理。

那怎么简化？这就是设计模式出现的原因之一了。设计模式就是对前人经验的总结。在有设计模式之前，类与类之间通过 new 关键字建立相互之间的关系，意味着类与类之间的关系需要调用方来进行维护，而维护的前提就是需要知晓被调用方。

设计模式如工厂模式，就是引入了第三方角色，由第三方集中统管类与类之间的依赖关系，调用方此时可以不需要明确知道被调用方，将由之前的 1 X N 的关系变成和第三方角色的 1 X 1 的关系，简化了复杂度。

调用者获取被调用者将由 new 变成 get，由创建变成获取，但是创建和调用被调用者控制权还是由调用者掌握。

最后，调用者释放控制权

在上一步共识中，调用者释放了类与类之间依赖关系的维护，将依赖关系维护交于第三方角色（对象创建工厂）维护，但是调用者还掌握着创建和调用被调用者的控制权，此时调用者连个也想放弃，交与第三方角色控制。

要实现这一步，一般来说需要借助于配置文件和反射机制了（不解释具体原理了）。

通过配置文件和反射机制并结合工厂模式，类的创建工厂完全可以实现类与类依赖关系的维护，类的创建，类的实例化，给调用者直接赋予被调用者实例。

调用者获取被调用将由 get 变成 set，由自身主动获取，变成被动接受第三方的给予。

其实Spring Framework 实现的就是上述工作，只是由开源组织统一实现了，我们不需要自己做这方面的工作，直接拿来主义。

当然了 Spring Framework 不仅仅只有 IOC 容器 ，还有 AOP ，声明式事务，集成第三方优秀框架等等功能。

个人觉得可以换个角度思考这个问题，而不仅仅阐述一下IOC容器的实现原理等等，当然了通过上述的思考，也可以知道IOC容器就是反射机制+工厂模式，结合配置文件实现依赖注入，实现了控制反转，相关的概念也就有个比较清晰的理解，不会那么生硬。